The online racing simulator
Searching in All forums
(583 results)
Scawen
Developer
The AI have had many improvements that mean they can get around in most vehicles on most tracks. They have an adaption system that deals with brake balance etc. (you may read the thread, it's long).

Previously they were very optimised for the LFS vehicles and not adaptable enough for mods. So it's possible that for some LFS vehicles, they are now slower, because of the small safety margins they must leave in order to not crash so many mods as they did before.

But...

1) Your thought of "scam bots" is totally against my philosophy of game production. I have no interest in giving AI extra grip or fake physics or whatever. One thing I learned is that I am nearly incapable of working on things that I'm not interested in, especially when the work is so intellectually demanding as coding. The AI in LFS use the same physics as the player.

2) This is not a good time for me to waste more time, trying to make AI faster in the old (current public) physics system. If you had followed the thread, you would know that I am trying to release this update as an official version, so I can finally work on the version of LFS we are all waiting for, which has new tyre physics and AI that is already adapted to that new physics. So as I keep saying, I'm not working on the speed of AI in the current public version, fake physics for AI (never will do that in my life) or any other physics changes. There were some slight physics changes done to make the bike handle better, but I'm sure I made it clear that's as far as I was going.

So... to summarize any relevant point, it is possible that official cars or some mods actually run slower, but as mentioned, the mods in general can actually stay on track instead of spinning off at any tricky corner.
Scawen
Developer
I understand why you chose to use unrealistic settings before, even if I don't agree with that approach.

To make a good mod in the proper way, the thing is to get as accurate values and settings as possible. If there are physical problems it's really my job to sort that out by improving the physics model. I do understand slight tweaks to mods to deal with imperfect physics.

But the mod still has massive downforce now, even after the steering model changes. Speaking as a mod user (not as a developer) I'd like to explain that makes me simply not want to use the mod at all. No bike in the world has F1-style downforce, as it's impossible. In my opinion the undertray should be deleted, the downforce set to zero and then work on the bike's geometry, mass, weight distribution, suspension, drag, etc. to make it as near to a real 600 as possible, then it will be a fun mod to use.
Scawen
Developer
Quote from JayDeM :May I ask what you mean when you reference incompatible version?

I've already done most of the work for an incompatible version, with improved mod support. It's a relatively minor update, an intermediate version still using the old physics and graphics, but has better support for mods.

It's intended to become version 0.7E after a short period of testing. I hope the short period of testing can begin in about two weeks from now if I can finish a few things.

Some of the updates in it were listed here: https://www.lfs.net/forum/thread/104758
Scawen
Developer
Quote from evandroPRO123 :Is it possible to add an on/off switch to the "miscellaneous" tab for the motorcycle's steering system? I believe that if there is a way to walk with the stabilizers turned off, it is possible to maneuver, so that the stabilizer does not interfere, thinking that we would fall

No, I think you believe that there is a separate system that is acting as a stabiliser. In fact the entire balancing mechanism and steering are lumped together into a steering model. The user sets the lean, then the steering model attempts to achieve that lean solely by adjusting the front wheel steering. It's a very challenging coding task, as you can see by the two weeks it took me to get to D45, after D44.

The solution I would really like, as mentioned before, would be to have a "physics" model (simulating gyroscopic effects) and a separate "steering" model that is applied on top of that, but that is not the case at the moment and will not be the case, certainly in the 'old' LFS physics.

As I say, quite often, I am trying to get off this test patch so I can get back to the new physics so I can release the new graphics system that everyone wants. If I don't finish it, then it can't be released.

I don't think everyone understands quite how extremely active this bike balancing needs to be, to keep the bike upright at all. Without the steering model constantly adjusting the front wheel, the bike will fall instantly. For example, if the user had direct control of the handlebars, it would be impossible to keep the bike up. The balancing code is actually adjusting the steering 2000 times per second to keep the bike upright.

At this point I will only fix serious problems. I'm not going to be working on the bikes going off road in the old tyre model, or implementing a full bike physical dynamics system at this time.


EDIT: The only system like "stabiliser" that balances the bike using external forces is the "walking" or "feet down" model that takes place up to 2 m/s (7 km/h). Above 7 km/h all balance comes from the front wheel, attempting to achieve the lean angle requested by the user input.
Last edited by Scawen, .
Scawen
Developer
Bike riders, please can you test the new bike steering model in D45? It's a lot more stable when changing gear and braking, also it should be better at low speeds thanks to a separate low speed model.

I'll read the other posts since D44 again and make notes to see what I can do or reply as needed. My main focus has been trying to improve this bike model which became less stable due to an improvement in D44. In this version, the underlying physics is unchanged, only the code that steers the front wheel is different. After the bikes are done, I can get back to finish the intermediate incompatible version with improved mod support, so finally I can get back to the development version and new tyre model.

This diversion onto bikes has taken a lot longer than expected, but I know there are a lot of people who enjoy the bikes and I wanted to make it more acceptable for now.


Changes in D45:

New more stable steering model for bikes:

Improved handling and braking ability
A new high speed model is used for speeds above 72 km/h
A special low speed model is used for speeds below 36 km/h
Models are interpolated between 36 and 72 km/h

AI:

Bike can now brake harder (safety margin the same as cars)
FIX: A hang generating path for a mod with "Max up" wrongly set
FIX: Downshift avoidance was too strong (sometimes needed clutch)

Interface:

A message shows the name of any mod that can't be loaded in an SPR


Download:

https://www.lfs.net/forum/thread/102117
Scawen
Developer
Thank you all for the feedback.

About bikes, I can clearly see the issues you report, not only wobbling when braking from high speed, but a lot of movement when coming off or applying the throttle, or tapping the brake a little when leaned over.

I've experimented quite a bit but haven't got any conclusive improvements yet. It seems like I can dial out any issue but doing so always causes other issues at other speeds or conditions. For example I've been able to get really nice accelerating and braking while leaned over at medium to quite high speeds, but then it's a lot worse when the bike hits a relatively small bump and seriously overreacts. The trouble is that what I call the "damping" part of steering (that tries to reduce wobbling by bringing the lean rate near zero) needs to be quite high to react quickly to certain things, but it needs to be gentle in other situations.

I also tried the early stages of a more physical model which tries to simulate gyroscopic forces and really apply steering forces to that. To separate a bike's natural handling, from forces applied by the arms. But it seems a little distant for me to produce such a genuine physical model at this time and I'd rather not do that with the old tyre physics. And a complete model would need body movement too, which isn't for now.

So in that case I'm left with the original plan to improve our semi-physical model (the bike is in physics but the steering is just doing what it needs to do to balance that bike at the required lean). I still hope to improve it, given my increased understanding learned last week, now that we have better bikes and more of a range to test it on, it seems like I should be able to improve it in some way.
Scawen
Developer
Quote from JayDeM :Hey scawen! can you give us a bit more info on what was changed for the motorcycles? I know you said it affects lean angle and tyre forces but was wondering if we could get a tad more detailed Smile

Yes, actually there were two things.

1) Insufficient lateral acceleration for given lean angle.

When testing for another bug (with a lot of bikes on track) I noticed that the mod "VELOCIPISTO" kept running wide. After a lot of investigation I discovered that any bike with relatively heavy wheels and a light bike would run wide. At first I thought it was a bug in the AI code, but much experimentation didn't solve the problem. I took the observed issue to an extreme with an extremely light bike and thin wheels with no rider. What was actually happening in that case was the bike could lean A LOT but the lateral acceleration did not match up. For example, by the laws of physics, if a bike has thin wheels, and rides in a circle at constant speed, then with 45 degree lean, the lateral acceleration should be 1G. However, this was not the case. For heavier bikes, the wheels are relatively light compared with bike+rider, so the anomaly is not that noticeable.

The actual physics flaw: It turned out that the weight of the wheels was applied at the contact patch, rather than the centre of the wheels. Through all the years, this had never been noticed. Actually, this is because the effect is so tiny for cars, as the wheels are vertical, it makes barely any difference if the weight is applied at the centre of the wheel or the contact patch. For this reason, I've left it the same for the cars, mainly to preserve the hotlaps. It is fixed in the development version for all vehicles, but in the public version it is in a special version of the physics update used only by karts and bikes.

2) Front wheels taking a wider line

I had kept noticing that the front of bikes took a significantly wider line than the rear wheels. It doesn't match up with my observations of real bikes. During my initial investigation of the lean problems noted above, I tried something which was to simply remove the effect of "camber thrust" and rely purely on slip angle to provide the lateral force. I was able to make this only affect the bike wheels, so that, again, the car physics are unaffected. In reality, camber thrust is a real phenomenon, so just removing it isn't really the answer. But the actual answer is to release the new physics that I have in development, and make sure that camber thrust is correctly simulated there. Apparently, in the current public LFS, it is excessive, or at least was excessive at large lean angles, leading to the strange slightly sideways motion of bikes around corners. Anyway, it looks a lot better now and I believe the bikes have a more stable lean angle when throttle or brake are applied mid-corner.
Scawen
Developer
Test Patch D44 has some more improvements including better (safer) braking and faster bikes. I've tried to deal with some of the issues that come up when bikes are allowed to go faster.

Mainly:
- improve line following by fixing a physics flaw
- taking off over bumps at high speed
- braking too hard for their ability
- unnecessary downshifts

The bikes are a fair bit faster now but there are some issues, with some bikes on some tracks. If you have problems you can turn them down to (approximately) their D43 speed by selecting OK instead of PRO.

Examples:
- Mod 'Cruiser' keeps crashing at AS4 due to wobbles at speed
- Fast bikes crash due to bumps before the South City underpass

I can't yet make LFS detect which bikes will be a problem so should go slower, or detect where fine bumps will bounce them into the air, but it's more fun to let the AI go faster so at this point I think it's better to leave it up to you to slow the bikes manually when needed.

The car AI drivers are better at staying on their line at the corners because of two changes: (1) taking account of engine braking and (2) allowing an extra safety margin when braking. In some cases they may be slightly slower but it's a reasonable price to pay for much more reliable AI across the board.

Other known issues:
- AI can sometimes stall but don't know how to restart engine.
- Some karts at some tracks can repeatedly regenerate path (waiting to reproduce).
- AI were reported as being rougher in D43. Maybe they are better now they have a braking safety margin?
- EV regen does not correctly match brake force. E.g. front and rear force arrows not equal at 50% balance.

Changes in D44:

Misc:

Improved bike physics (affects lean angle and tyre forces)
FIX: Engine brake reduction had no effect for EV but was visible
FIX: Replay OOS after a reset attempt was prevented and long wait

AI:

Bike cornering and acceleration limits increased by 25%
Bikes slow to avoid taking off over large humps in the road
AI braking prediction now takes account of engine braking
Braking prediction includes a safety margin to avoid late braking
Avoid unnecessary downshifts by looking ahead to see if needed
Reset is available even after engine switched off after long wait
FIX: Sometimes could reach a maximum speed and stop accelerating

Download:

https://www.lfs.net/forum/thread/102117
Scawen
Developer
Quote from racer35 :Thanks for the info. So just to confirm, wherever you set the rider position in "object positions" is where the rider always remain from a mass perspective?

Yes, the mass of the driver is currently represented by the light yellow L shaped object, and the animation is visual / aesthetic only. It's not very satisfactory but that's as far as I got before we released the whole mods system. It was a reasonable representation in cars but for bike we will really need something much better.

Quote from bayanofmansorofisky :@scawen Please allow movement values greater than 1 meter on axis for spare wheel..

In the incompatible version I have been working on, that will be released soon (not the new physics and graphics, I'm talking about an incompatible version for mod support with the same old physics and graphics) I have done some updates for spare wheel.

Option to include a left or right spare wheel (or both if offset)
Option for single spare wheel to swap side when driver swaps side
Option for spare wheels to be based on rear or front wheels
Spare wheel heading can now be set (as well as lean)
Spare wheel offset can now be up to 1.25m (like road wheels)
Spare wheel vertical (up or z) position can be set up to 2m
Option to include hub object with any spare wheels

Scawen
Developer
Thank you all very much for the feedback and reports since Friday's test patch (D41).

Tankslacno, that must be the best presented patch report I have ever received! Smile

I am fixing the things which are definite bugs, especially if they were introduced recently. Some things won't be fixed but I will look at all the reported issues and see what I can do in a short time.


NOTE: I seriously want to move away from AI, as soon as possible, to get back to finish and release the recent updates to the mods editor and system (the intermediate, incompatible patch with the existing physics and graphics). So I'm just trying to round off the most important issues.
Scawen
Developer
That is exactly what I will not be doing for the AI in the old physics system. Anything related to grip, tyres, etc, would be a waste of time because it would not apply to the new tyre physics. As mentioned, I've already made the AI better at using the available grip in the development version (although there is far more that could be done).

For this update that I've been working on for a few days, it's the overtaking that I am improving. The recent, unscheduled, look at AI (started by watching the bike AI) alerted me to the problems with overtaking and ramming.

Work on this applies equally to the public version and the development version, so it's not a waste of time.
Scawen
Developer
I've done some updates for overtaking that more sensibly group the cars in front together, instead of taking each one as a separate object to pass. It's hard to describe in words, but it boils down to a single "left" or "right" or "brake" decision on the group, instead of doing that separately for individuals then choosing one of the results. It means that more sensible decisions can be taken. Also it can add more AIs that aren't directly in front but are beside the cars that are in front, so hopefully they can make their way around a pileup. It's not a navigation algorithm but makes a better estimate of how far right or left it may have to go.

Just for the record, the bikes aren't slow because I have somehow failed to notice that they are slow. It's because if I turn them up any more it is very unlikely they will make a lap. They'll run wide or ground out or wobble at a bump and generally wipe out far too often. The bike AI are super sensitive to bumps and jumps in the road and as I mentioned before, there are issues with the tyre physics. So bike AI speed is not something to spend a lot of time on at the moment.

Years ago I updated the development version quite a bit, to make the cars a bit more competitive. Unlike in some games, the AI in LFS use the same physics as human drivers, and it's not an easy task to make them simply drive faster. The level of understanding for where you can push and the lines to take, is not an easy thing to code.
Scawen
Developer
Thanks for the feedback. I've released D40 which should solve some issues and hopefully doesn't introduce serious problems!

Quote from UnknownMaster21 :AI seems to wobble it's bike on certain tracks.
...
Most likely on AS4 and KY3 ( when entering track from pitlane )

I think wobbling is worse on some bikes than others. I tested with 6 bikes on the tracks you said, and the only one that really wobbled was the Mosquito (with passenger). I found it hard to improve wobbling when I looked into it the other day. I think that will have to wait for the new tyre physics. But if there is a situation where many bikes wobble, I'll have a look.

Quote from Bokujishin :...I found 3 issues with them:
  • At the start of the race, most AI have a very poor launch, as they brake for no apparent reason and also swerve quite a lot (see XRR replay).
  • Some cars can end up in a massive pileup and stay there for a while for no apparent reason (see XRR replay).
  • They tend to "move under braking", or at least AI FBM do, especially if you're on the outside and force them away from their line, they tend to move to the outside and push you (see FBM replay, where I try to force AI out of their standard line, especially at T1 on lap 3).

The first item, is probably that reported by bobloblaw above, which should now be fixed.
The second item, I noticed this, it was a newly introduced bug, now fixed.
The third item, I'm not sure about. It sounds like something that could have always been the case. Or do you think it's something new?


Changes in D40:

- Safer bike overtaking distances (hopefully not too far)
- Consideration of barriers more dependent on current offset from ideal line
- Distance to vehicle ahead considered dangerous, now depends on length of vehicles
- Much more likely to attempt overtake, when previously stuck behind a slower vehicle
- FIX: Could brake if slightly faster than another car but the other car is accelerating
- FIX: Sometimes applied brakes and stopped on track next to another vehicle

Download: https://www.lfs.net/file_lfs.php?name=LFS_PATCH_7D_TO_7D40.exe
Scawen
Developer
As an old rider, I am interested in making the bike riding a lot better. At the moment the rider animation doesn't affect weight distribution in any way, it's purely aesthetic.

It's a complicated project to be done at some point but I'd like the rider to be able to sit up for braking, get down for high speeds, move sideways for race style cornering. And also move hands with the bars correctly even when the body is in a different position. Combining animations (or some kind of physical arm and body system) is not an easy task but is something I am interested in, as some people might know from the creatures in Lionhead's original Black & White. Smile

It's not a task I can take on in the near future because it's really big and of course it's massively more important to get the new physics and graphics update released.
Scawen
Developer
I hope the improvements are all good. Yesterday's overtaking improvement should apply to all AI.

I assume that mixing different vehicle types, and AI driving large vehicles, are no worse in D39 than they were in any other versions. If anyone can show that anything has got worse, I'd like to know about it.

I suppose the code for AI to avoid collisions is built on assumptions that the other vehicles will follow similar lines and be at similar speeds, as they would in real racing. The old LFS tyre physics is stretched to the limit (or should I say beyond the limit) with bikes and heavy vehicles. At this point I don't think it's a good idea for me to spend any time trying to make AI drivers work any better with the old tyre physics. Instead I should get back to finishing the intermediate incompatible update with improvements for mods.

As mentioned, I would like to hear if any AI behaviour has got worse, or any more specific and repeatable issues with the new bike AI.
Scawen
Developer
I've done some AI updates and copied them into the D37 test patch.

AI can now drive objects (do nothing) or motorbikes (slowly)

EDIT: AI can also enter in configs with no path, but will just sit there.

This started from a request to allow the AI to use objects, so they can be tested offline. It's an old thing on my list. But it seemed best to allow all mods, not just objects. That means motorbikes had to be supported. Well, a "few hours" turned into quite a few days. So, sorry about the delay to other things. I have stopped short of trying to really get the best out of them. There are issues with the tyre physics and the bikes actually work better in the new tyre physics.

If you are interested in object mods or bikes, please have a go with the new AI code. It was hard to get them to go round at all on bikes, then there was quite a struggle to get them to leave or enter pits. Hopefully I haven't broken anything for the other AI!

EDIT: Some bikes are too wobbly and crash too often, but maybe you can let me know if enough bikes seem to ride OK at enough tracks.

I know some people will be upset at another delay, but this is an important part of finishing the mods system. Other people will have fun using these AI updates. I've still got the incompatible updates including wheel rim improvements to release in the next few days.

https://www.lfs.net/forum/thread/102117
Last edited by Scawen, .
Scawen
Developer
Hi Morfeas,

A solution is now available. Sorry you had to wait so long.

I was working on something else related to gear shifts so I decided to focus on this specific issue today. I have now made it so that a "fake key press" initiated by a mouse wheel move now lasts for 100ms.

Previously it was as if the key was only pressed for one physics frame, which was not long enough to do the gearshift. Although the ignition cut happened (as you said) the drive train did not become unloaded during that single physics frame, to allow the shift to take place.

The solution seems very reliable to me. I hope you can test it when convenient.

https://www.lfs.net/forum/thread/102117
Scawen
Developer
I can't give any better estimate when the 1000 Hz update will be released. Eric is currently working on significant updates for Kyoto and I am trying to finish an intermediate semi-compatible release of the public version with improved mods support.

After that release I'll be trying to finish the new tyre physics and the plan is to release that with the new graphics, as both are in the separate development branch of LFS. I have no more information that that, at this time.

---

About the FF display, I seem to remember someone did a mockup of a way that a native FF display could work. Can anyone remember that, or does anyone have a good idea for it, how it could look, how it should be enabled? Should it be something like the display you can see when you click the small car button in Misc or Graphics options (a lateral graph moving up the screen).

Half the issue implementing something like this is the general design and the interface for it. Another significant problem with adding things to the screen are all the situations that can come up when trying to display the new feature at the same time as other things on the screen, so if you could help sort out the details that would be helpful.

I have a slight issue at the moment that whenever I try implementing some "simple feature that would be very useful" I end up spending several days or weeks sorting out all the repercussions that arise. So the thought of taking on yet another task is a bit nerve wracking right now.

By the way, in the development version I do have a simple "MAX FF" red text that comes up in the middle of the screen in the same place as the usual large text. It might be a bit too raw for a public release. Obviously this would be a lot simpler to implement than a graph. So that approach would avoid delays but I'm not sure how useful that would be, compared with the full graph display. Also would it need an option, like "Show FF clipping" NO / YES.
Scawen
Developer
I've done a test and made a change.

The long vehicle falls through because it is long and there are too many objects in the vicinity. It's not because the wheels are big. The objects in vicinity are calculated by an inefficient method that is better in the development version of LFS.

In your version, it runs out of slots for physical objects. I've increased the maximum from 64 to 80 and the long vehicle can now drive in that place you described.

About the bridge, it still does fall through the ground at that point behind the WE pits. There are simply too many objects nearby. It's because the assumptions that the physics system is based on do not apply to such large moving objects.

At this point, I think it's best to leave it at that. Longer vehicles are less likely to fall through the ground now because of the increase from 64 to 80. I don't want to increase the limit much as there might be consequences I don't want to deal with.

---

About your other suggestion, it has been on a list for a long time to allow AI to "drive" objects (i.e. sit there not doing anything). I enabled that yesterday. But so far they aren't allowed in to configurations without a path (same as other AI). But that restriction makes no sense for objects as they can't follow a path anyway. I'm thinking that the solution should be that AI, driving any mod, should be allowed in configs without a path (but simply sit there not doing anything as they have no idea where to drive).

This would allow people to test custom layouts more easily, for example start grids could be tested properly by AI drivers, even if they don't drive anywhere. I'm not seeing any issues with this, as long as LFS will somehow tell the user that the AI can't drive a car on that track.

I'll have a go today to see if I can allow AI on all configurations. It's not high priority but would be useful if I can do it easily. I hope it doesn't lead to any further complications I haven't thought of.
Scawen
Developer
First thing I'd like to say is that, I agree, it would be great if LFS would store locally obvious things like PB and splits for any vehicle and track combination, and these recordings of your best lap so it can show live delta, and these other live statistics for racing (relative to other drivers, in better detail than the existing native system).

Second thing I have to say is that I can see quite a lot of complication with it and the various options these systems would need. At the moment I'm trying to finish an incompatible version, to then get the new tyre physics into a releasable state so we can finally release the new version. So I really can't take it on in the near future.

I'm wondering if any other programmers could do these, and if anything needs to be added to InSim to enable it. I know we have programmers with the skills to do it and probably the interest too, but programming is time consuming and programmers may be busy on other projects and work, so aren't ready to take up such a task. But in case anyone does want to at some time, before I can support it natively, I wonder what needs to be added to InSim. I know that LFS Lazy uses a combination of InSim and direct memory access but it would be very good if the direct access could be avoided. So if any programmers know what's currently missing from InSim and could enable such excellent features as seen in LFS Lazy, please let me know.
Scawen
Developer
Quote from RE Amemiya :More and more I find that having the spindle offset forward or backwards to adjust the trail independently of the caster is a missing essential piece to accurately replicate many real life car suspension geometry. I see you do have the option on the motorcycle forks, but we could definitely use it on the cars as well.

As I'm on an incompatible update and this was simple to do (enabling existing code for bikes to work on cars) I've done that. But it currently only works as positive "Trail reduction" which means moving the wheel forward. This is always the case on bikes because of the relatively high caster that would produce too much trail.

You said "forward or backwards" so I want to check if it's definitely needed to be able to move the centre of the wheel backwards, behind the steering axis (i.e. negative trail reduction, with the result of increasing the trail without increasing the caster angle).

---

Other people: thank you all for the suggestions. I'll be checking the thread again before the release to make sure I do some of the things that can be done without taking too much time.

By the way, the release I am talking about is the 0.7E version still using the same old LFS physics and graphics system and with some improved mod support, mentioned here.
Scawen
Developer
Thanks for the reports.

For three issues, I've released a minor update, Test Patch D35.

Quote from henricat2006 :I don't know if it's the right place to report this bug, but depending on the position of the camera, the motorcycle's handlebars disappear, if you set it as a steering wheel, this doesn't happen.

FIX: Mudguard / handlebar / trailing arm remain visible if wheel is off screen

Quote from chucknorris :Ah yea, maybe that option should be on by default and off by opting in.

Misc option "Full physics for remote cars" is now enabled by default

Quote from chucknorris :I've came across another issue related to narrow cars.

It seems like when the track width is below a certain value (eg 800mm), the cars are getting "sucked in" into objects.

FIX: Narrow cars were sucked in if driven too close to fence or narrow barrier
Scawen
Developer
Minor update D35:

Misc option "Full physics for remote cars" is now enabled by default
FIX: Narrow cars were sucked in if driven too close to fence or narrow barrier
FIX: Mudguard / handlebar / trailing arm remain visible if wheel is off screen

https://www.lfs.net/forum/thread/102117
Scawen
Developer
Thanks.

This problem can be eliminated by the "Avoid simple physics" option (that also prevents remote cars with high anti-roll settings jumping on the start grid).

The equivalent of "Avoid simple physics" is always set for karts. I'm wondering if it should simply be enabled for all vehicles now. There is a certain CPU cost that can be observed by pressing the F button in the CPU usage display (available at top right of Misc options).

The trouble with your mod (without looking into it in detail) is the wheels are small and light. The "simple physics" doesn't operate at a high enough frequency to remain stable, although it is handled fine by the normal physics.
Rim editor updates coming soon
Scawen
Developer
Hello mod developers.

As many of you know, I am trying to get to a full version release so that all racers get the benefit of the recent updates, which I won't list here (you can read the first post of the editor test patch thread).

I noticed that some people, who want better looking wheels, have been using workarounds for deficiencies in the wheel rim system. So I really had to sort that out, even if it delays this full version release and my subsequent work on tyre physics. Sorry to the physics purists but I can't really leave the editor with such glaring issues. Wheel designs are very important and some people are putting a lot of effort into their mods. It's not good to have more and more mods with workarounds for a system that needs changing. So I have worked for a few weeks on this system for rim and wheel graphics.

Here I will list the updates and then post a few pictures:

Wheel rims:

Rim can now be fully edited, there are no fixed surfaces
Rim no longer blends seamlessly into the wheels without an edge
Allows more design flexibility for alloy wheels and steel wheels
Removed: edge extra width / lip depth / inner depth / black inner
A simple alloy style edge is automatically added to existing rims
Option to allow separate wheel style (rim/spokes) for front & rear
Tyre vs rim guide in the vehicle editor helps set correct rim size
Rim has 60 segments around instead of 30 (tyres still 30 around)
Rim guide in rim editor shows regions that should be covered
The colour at the bottom of the list can now be deleted
3D view visible in rim editor can now be rotated

Wheel lighting:

New ambient lighting system for wheels and spokes
Separate options for front and rear "concealed wheels" lighting
The new lighting system replaces the old 'rim shade' option
Auto repair removes the Dx/Ex darker colours from rim

The new lighting system affects both the rim and spoke objects. The lighting at each vertex depends on its depth in the wheel and the direction it faces, by an approximation system that is also affected by the "concealed wheels" setting (that makes it darker on the inside).

I think this ambient lighting should also be applied to any 'brake' or 'hub' objects that are found, because they are also within the wheel cylinder. But let me know if there are other uses for such objects, that mean the new lighting shouldn't be applied to them.

More notes:

I would advise mod makers not to use rim workarounds for now, as the auto repair is likely to affect the look of your work in the rim flange area. It's probably best to go along with the default LFS rims at the moment. If you do use workarounds, please be ready to fix your mods as soon as the update is released.

The update will be incompatible. Not for physical reasons, but simply because the file format is updated. That means, old LFS will no longer be able to load mods saved with the new version. There will be a test patch that can load the newly saved mods, of course. I will start a few test servers for people to test their mods, during the short period of time when the incompatible test patch is out and we are in final testing before the official update. I hope that period will be only around two weeks, to allow enough time for testing.
FGED GREDG RDFGDR GSFDG